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i>uoJecf* MJlfiCS JataOoie Management Facility 



Ihis MTS proposed an overall design approach tor 3 jaTabas^ 
management facility for Muitics. The proposals set forth here 
shall be rns topic of a Rew ie*i Meeting ro be hela at Camurujc 
(CISL) during tne week of Feoruary 10» 1375. Any questions r 
comments can be sent to me via Muitics mail (Fnesen Muitics). 
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Multics Jafaoaie Manager Preliminary Program Specification: 



1. Intro auction 



ThxS uocumsnt proposes an overall oe.aign for the Multics 
uataDase Manager {03M). It discusses the philosophy of the 03M, 
presents a oescriotion of the sjftHaffe included as part of th- 
system • ano sets forth design goals. If is intended that this 
oraf t will oe consiuer^d d focal panf for discussion of possible 
revisions or enhancements to the JdM. out of which will emerge 



t n t find* 



■ogram specifications* 



1.1 Purpose 

Tne Multics JBrt shall oe oesigned 

-to provide tne user with a logical (rather than 
physical) view of the dataoase. 
-to allow dynamic reorganization of inn dataoase With 
as little effect as possiole on the applications 
usiny the database. 
-to provide the user with simple, versatile and secure 

access to the Odfaoase. 
-to allow definition of tne oataoase oy means of a 

Oata description Language (DJL). 
•to allow manipulation of the oata witnin the dataoase 

oy means of <a Data Manipulation language (UML). 
-to provide the user witn some means of recovery and 

re start. 
-to provide the user witn the advantages of "1-0-5 
II-liKe capabilities." 
T^e purpose of rne Multics 08M is to provide an integrates 
s c f -if functions to support the description ano processing of 
lofge uataoases for the Qusiness. academic ana governmental 
common 1 1 ie-a. 



1.2 S-ttwa--: Design Philosophy 



S ever a I f actor; 
ot th* propose o 
s i g.n i f a cant e * 



nave influenced the overall design onilosophy 
UdH. The following factors a~e of special 



-envi - onman t 

The OBM shall operate as a Multics 
subsystem using m* Multics file system tc 
advantage ano shall be written Ln the PL/1 
programming language. This will provide 
ease of program maintenance as well as 
consistency with ofner Multics software. 



MTB-1^7 



Page 3 



language interfaces 

Ratner than extend The syntax of any host 
language, the dHL Mill oe designed to 
interface with its host languagt via the 
CALL statement. This wi I I provide a 
relatively Simple interface mechanism and 
avoid tne prooJem of .modifying tne nosT 
languaget Initially this interface Mil I 
oe provided for PL/1, but if could easily 
oe extended to incluae FORTRAN and COBOL. 



similarity to l-Q-S II 

A prime consideration is to offer th 
"I-J-S II- like capaoi I i ti«s. " Thi 
oeen interpreted in a general sense 
user wi II oe provided ' with tne g 
functionality of I-D-S II wnicn in 
tnose functions "rejjirjj ro suppor 
description* manipu I stion, restrucf 
recovery, security, arid analysis of a 

case." (I-0.~..^... T X..I',,t-DS» P» 
Specifically, the dataoase on <<nicn t 
operates snail be cepacia of supp 
singular, hierarchical ana network 
structures* 
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aata independence 

Data independence is a Key objective of the 
OfaM. Consequently, the concepts of schema 
and suo-scnemas have oeen utilised. Also 
contribdting to datj independence is the 
use of context variaoles to reference date 
elements logically from within tne DHL. 



dataoase ~ecr ganiza t ion 

The 03M shell 
reorganii ati on 
rec 1 us f er mg) » <iS 
the def a sha I I 
consuming process. 



ce designed so tnat 
of the dataoaseti.e., 
well as restructuring of 
not oe a costly and time 
Fur thermo~e , dafaoase 



reorganization shall h^ve a minimal effact 
on user application programs wnich us= the 
database. 



- recovery 



Database rbzouer^ and dataoase integrity 
are two mare key oojecfives of tne Q3M. 
Consequently, tne ObM shall include 
provisions for manually "c I eanpoi n r i n a " the 
dataoase. This will allow for "clean" 
dataoase dumps to tape and provide 
assurance that tne integrity of a dataDeSe 
is not impaired during recovery of tne 



Mlb-m? 



P a g e *t 



jatatasa • 



1.3 Sfulfics ana I-Q-> II 

Th t imp I amenta T i jn of 1-0-3 II on the Multics system has 
oeen cjniidereJ to be a desirable objective. This wcuu seem To 
Dc True only if 1-0-3 II »s defined in the most general of terms. 



Some j.-0-S II features seem to oe aT 
philosophy if Multics operating procedures. 



variance with th< 



- 2 h a i r. s 

lne concept of "chaining" records together forces a 
coriSid3"abl e jegree of "harj to change" structure onto a 
uataoase. For instance* it is quite difficult in I-D-S II 
to aeclare an existing record type to be a new memoer of an 
existing set. Tne imposition cf this sort of permanent 
external structure seems to run counter to general Multics 
philosophy. In Multics the actual Binding (i.e.* 
structuring! of data is usually conceiveu of as a dynamic, 
"afher than a static* process. Ihe "oinding" of data 
elements, is usually postponed until the last possible moment 
(at execution time* for example). Admittedly aata elements 
i r< u safjbose must De structured to « highe~ degree man 
non- o<5 1 oOdSe elements oecause of tne necessity* m»thi~: o 
oafabase, to carry along (or "re memoer") relationships. 
Newer tne I ess, it jeefiis advisable to allow such re I at ionships 
to oe as dynamic as possible. 



The "-hdining" of records also fends to lose much of 
4 ts usefulness as the chain pointers become more 
interpretive. Thut is, the most efficient chair. pointers 
ar= those wnicn are nur dware oriented. 
realistic to think in terms of hardware 
within the framework of the Multics virtual 
the Multics file -.ystem. 



But it i s no t 
oriented chains 
memory system or 



the 



entire concept of "chaineo ' 
. „ „_ ,. only -limited value with reference 
ics operating environment. 



Lonscqu^n 1 1 y * 
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•4 re as 

Ihe concept of "area" » as used by i-ii-S II, seems well 
sui teu to I-ii-S where it is necessary to "reserve" a numoer 
of file pages prior to usage because the CALGing algorithm 
is dependent upon tine total numoer of file pages assigned to 
fh_ file (or irtai or database). The concept is also a 
"natural" for 3G0S users wno nave become accustomed to think 
in tt-rms of reserving file space before actually uiincj the 
tile. 
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The "jrca" conceot, however, seems alien to the 
philosophy ot Multics wherein "file space" {or virtual 
memory) is allocated and used as needed. 

There are iuica inherent shortcomings in I-Q-i II /vhich ought 
to be avoided if af ail possible. Tnese Disadvantages are 
essentially the same as those listed in I3M*s critique of DBT3 in 
the "Position Paper Presented to the .iuQASYi. Programming Language 
Commit tee" ddfeJ May, 1971. They may ue grouped under thrtr 
general headings of data independence, dataoase recrgun iia r i or. 
and DML complexity. 
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•Database Reorganization 
I he reo~ganiia t ion of an I-O-S d 
fear in tne heart of a user. Not 
ana time consuming, out it may al 
user programs. Nonetheless, it i 
tne type of demands made upon a 
passes. As these changes develop 
some transformation in appearance 
are such as were not allowed f 
database design period, then rear 
cost, becomes a necessity, 
reorganisation a?*.- necessary, the 
as paiiJess as possiole. 



ataoase generally strikes 
only is the process costly 
so Seriously affect various 
s on I y re jsonao I e to expect 
uataoase to cnanye as time 
, tne database will undergo 
« If tne transformations 
or during the initial I-J-i 
ganiidfion, regardless of 
If instances of dataoase 
y ought at least ro be made 
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Attempts should oe maJe to overcome these obvious 
disadvantages of the I-O-S approacn t while at the same time 



iiir. ; .1, n i fha in 



rr.T.iuftn.n of other more serious shortcomings. 



2. Ubrt Opt~ating environment 

Trv- Multics U3M ii fo run as a Multics subsystem and wi II 
uofc trie standard rtultics file system. All aataset I/O will oc 
ptrform=d by the vfile_ I/O module. 



3. uafaoase Management System 

The UBM will consist of essentially three distinct parts: 

-those modules concerned with schema definition and 
o no cess ing. 

-those modules concerned with suo-schema definition 
3Td processing. 

-those modules concerned with run- time processing and 
data manipulation. 

Ao ji Ticna I I y rner = wi I i exist utility programs ot various types. 

ail u 3 M activity will involve interaction oefween t n e 
Mulrics fil= system au user programs. 



DcSxgn jDjcCtivas* 



-The 03^1 shall De designed to allow the user as mucn 
data in Jependence as possiole. 

-Uatabase reorganization shall be a function of a 
"database administrator" and shall not affect user 
application programs. 

-Data redundancy shall Qe kept To a minimum, ceing 
-iquirtJ only fo a very limited extent by The 
i n t i f y_key s (defined oelow). 

-The ^ALL interface fo~ the OML will make the 03M 
~un-time routines easily available to programs written 
in languages other than PL/1. 



3.1 DaTaoaSe Structure 

The- raw database will consist of a set of relations (files) 

ir, fhirj Norma r Form =»s defined py £. F. CoJld. The only non-jata 

attributes contained within the da ta_r e I a tions shall De the 

unique identifier generateo Dy tne OBM for inter-file linkage 
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purposes within the Mulfics file a/item. All filca created by 
The OBM sho II be ifsdtcJ oy the Multics file; system. Hence, they 
will De 3" : -free files ji uefinea oy D. Knufn. 



3.2 File Harjaling Procedures 

Lief in* t i ons S 

tils* is a Multics Indexed Sequential File. 

l&iallaa is a collection of entities. It can be 

t/isualized as a two-dimensional tsole wherein the 
entities arc the horizontal rows. ta:n relatior, as a 
iu I. tics file. 

iallly is a collection of a t f r inute- wa I je pa A r; 
establishes uf schema definition time. 

illciaulsi is analogous to "lielo name" on a may ue 
rf'isualized as the columns of u relation, t jtaolijnuj 
at schama definition time. 

_-lii2. iS <=• quantity dssociatej with each occurrence of 
an at tri out e » 

__ii.±.)L___}2. is the logical attrioute (or collection of 
at tribjTQS) which uniquely defines each entity. 

iai.iUt_2a.ih is a linkage Detween tne entities of two 
re lotions. A one-way entr y_pa th a I I ows passage from 
arj entity in Jot a_re I a t ion- A tj an aijociatcj entity 
iT jafa_re I at i on-ii. A two-way entry_oafh ilhws 
passage as well from the entity in j a ta_re I a t i en- j to 
the associated entity in da f a_re I a t i on-A. 

££.£.£C_ refers to the suo-scnema definition of ore or 
nors entities. If is the logical representation of a 
group of uftrioutei as seen oy the Jitr application 

program. 

F___Li refers to the sjp-schema .definition of an 
attriDute. IT is tne logical representation of a r. 
attribute as seen oy The user application program, 

As a general rule there will exist 

-one Multics file for eacn normalized relation. lra.z 
file shall contain all the attribute values of each 

■entity in the speci f led re I a r i on. Lach entity shall 
ae a logical record within tne Multics file. ia ch 
sntify shall contain one (or a number of) 
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at tribute (s) constituting an entity_key. The 

=ntity_«cy shall oe tfisiole to the user only if it has 
oeen explicitly jetinej by tne user. £aeh user 
viSiole entity Key shall proyiue the user With a 
"nandie" for that entity. E^cn entity shall 3 I so 
contain one attribute (invisible to the user) entitled 
3 unique_iJ. For tnose entities witnout a user 
tfis.ib.ie: entity_key, the unique_id attrioute shall olay 
tne role of an entity_key recognizable as such by the 
DBM. Tne unique_id snail contain a unique bit 

representation (generated by the O'JM) which will serve 
as a system identification tag for each entity. 

For example* a name_address entity with an entity_Key 
of persor,_njme might be representee as follows? 

stfrioufes! person_name str_auur City st unioue_ici 
snfityJ Smith Joan 101 E I m A'j o AZ f(t) 

wnere f(t) is a unique function of t and 
t represents the time of entity creation. 

This relation shall oe teamed a da ta_re la t i on. 

Properties of data_re I a t ions 

<> there Will exist one oata_re I a t i on for each 
normalised relation. 

<> iach entity within a data_re J at ion will ce 
assijneJ a uriique_id. 

<> each enfity_key rtifnin a late _r elation mo si oe 
unique within that Jo ta_re I a t i on . 

<> the ua f -i_re I a ti on Wi I I oe an indexeo sequential 
file indexed on ascending entity_keys. 

<> th= only user-v/i siD I e entry points into a 
oaf a_re I 3f ion are tne en t i ty_key s explicitly defines 
as such at schema creation time. 

<> if a oata_re lat ion is not to be entered directly 
by a user (i.e»» if if is to act as a seconOciry 
record-type in I-O-S terminology)* then the 
uniqua_id attribute for eacn entity shall also be 
the entity_key for that entity? such a da ta_re la t i on 
shall require no associated key_re I at ion ( def i ned 
oe I ow) . 



<> the entities within a data_re I a ti on Will contain 
fixed numoer of attributes Idf l=osr in the initial 
i inp lamentation). 
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•ane Muitics file for sact\ dat a_re I a r ion contain 
jscr ViSiole entity_key. This file shall contd 
tne uni que_i d and the enfity_key of The soecifi 
da tu_ra I a t ion. This file snail be indexed, in 
lultics file system, according to the itfributc 
of tne unique_id for each entity. This provide 



3i ine unij.ue_iJ i or sdtn eniiiy. iniu provui 
system- interna i I ink^y** mechanism amony the war 
relations. For those da ta_re I a tion s where tne 
jnique_id ana enfify_Key attrioutes are identi* 
there snail exist no key_re I a ti on. 

This file shall oe termed a key_re I a 1 1 or. 
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Properties of Key_re I a t i 01 s 

<> the only two affrioufas of an entity within a 
k^^_m I at Ion will be the entit/_key and its 
associated unique_id. 

<> the key_re I a tion will oe an indexed sequential 
file indexed on rne unique_id of the associated 
entity. 



<> th&rs Will exist one key_relation for each 
dafa.rdation, with a user visible ent A t/_ke/, to 
topically associated with ^notnur dat a_re I => ti on. 
That is, if an entit/ within a dot a_r e) a t i on is to 
be retrieved when its enfity_key is unknown, then 
there must exist a key_relation for that 
daf a_re I ation. 



Qc 



Will be as many entities within a 

there are entities within the 



<> there 
key_re I a f ion as — , _. - 
asscciafao data_re I at i an. 

•one Multics file for each one-way entry ,_„,.. ...... 

"elation. tach of these files shall contain two 
classes of attributes, consisting of the unique_id for 
trie source entity and a variaole number of umque_ias 
for tna ta~get entities. This file shall be indexed 

the source entities. In addition 



path in to a 




Tnis file snali oe called 



cross relation. 



Properties of cross_re I a ti ons 
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<> thsra Mill exist one crois.re I a t ion tor each 
entry_path between two da ta_re I ati ons. For example* 
if an employee ua ta_re I a f ion is such that it will 
always oe entered from a jepartment oa ta_re la tion 
and tne Jepartment da ta_re I a tion will never be 
entered from the employee da fa_re I at i or. (e.g., giver 
an employee's name* there will never be an attemot 
to retriev. that employee's department name)* then 
we may say mere exists a one-way entry_patn between 
tne employee and Jepartment uata_re I a t ions* 

<> there Will exist as many entities in a 
cross_re I a ti on as the number of entities in the 
associated source da ta_re I at i on. 

<> eacn entity within a cross_ra I a t i on will consist 
of two classes of attrioutes* as follows* 

itne uni.que_.id of th^ entity in rne source 
da ta_r« I at ion shall constitute tne inoexed 
sequential Hey (or index) 

•the un*que_ids of those entities in the target 
da ta_re I a ti on snail constitute the non-prime 
(i.e., non enfity_key) atrrioutes fc each 
cross_r<i I at ion entity. Tnere will exist as m a ny 
target unique_i3 attributes as there are entities 
associated with tne specified entity in the 
source oaf a_re I at ion. If the source 
uata_r j I a t i on has no user Visible entity_keys» 
men tne tar jet _niqje_ij will also oe an 
entity_key value. 
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6*3 Schfema. Processor 

Jhe schema itself shall de>c-iot a database physically 
arranged in a relational (i.e.* taDular) manner. Tne essential 
functions performed ay The schema processor will oe two* 

-it mill create, modify ana delete ail file:; 
necessary to represent the data as. defined oy 
ueclarations within the Schema Proc^sso". 

-if will store information aoout the schema 
structural to be used later oy the Sub-schema 

Processors 

The specific functions performed by me Schema Processor 
sia J I be to? 

-create a directory file identifying the dafauase 
with i given schema name* Wnen suo-scnemas are 
suosequeitly created* their names snail ce recorJed 
inthisdirectory. 



-maintain a list of all attrioufas and entity_keys 
along with th^ (Mulfics) file names of the 
data_rel ations in which they participate. The 
physical characteristics of each attribute; (e.g., 
Si2e* type, etc.) shall be described as a part of 
this list. Tha locks to 0e assigned to each 
attribute shall also oe a part of This list. 

-maintain a list of a I I da ta_re I afi on names along 
with tne attriDufest locks ana entity_keys 
associates with each of them. 

-maintain a list of all th^ en t i f'y_pa fhs existing 
armng all data_re I a t i ons. An indication whether a 
da ta_re la f ion is dependent upon another 
data_re I dtion will appear in thi^ list. 
entity is added to or deletea 
dat o_re 1 at ion t then the cross_ 

the associated da ta_re I a tion s must oe upaated. 
Otherwise* the cr o 5S_re I a fi on files would o c upaatea 
only if the associated da f a_re I a ti ons were 
referenced py the suo-schema in use). 
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> i m p I e as desireo. Care 



w scTsma may be as complex or as 

to insure that if is normalizea. 

ould oe introouced into j 



snoulu be taken* however* 

tlse* considerable inefficiencies 



use" application program which attempts to modify data. To 
a~aw a rough analogy with I-Q-S* normalization of a relational 
dataoase might oe comparea to defining a 
Oafa structure diagrams. 



database in terms of 
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3.<+ Suo-schema Praceiijr 

The Sub-scnema shall provide the user apolication program 
with its view of a database. It shall ue a suoset of a schema. 
The user application program shall oe allowed to access more 
Tnarj ^nt sub-schema and/or .schema 5.' 
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interfacing with the scheira, the Suo-schema Processor 
ly be aware of the name of the schema { i . a. » the 
c j a nd tha names of those attnoutes (and ent i t y_Key s) 
icn this sub-schema is concerned. In general it shall 
cessary far the user of the SuD~schem a Processor to oe 
eu with the names of the dat a_re I a tions ♦ Ke y_re I a ti ons 
s_relafions. A general knowleoge of the logical 
nsnips among the ttfribufes will usually suffice. Tne 
ema Processor will update tne list of sub-schema names 
ted with this schema. 



A sub-schema UOL. shall oe defined, initial ly» tor the PL/I 
programming language. 

Specific functions performed Dy the Suo-schema Processor 
snail include the following: 

-the associated schema directory file shall be 
upaated to contain the entry name of the specifics 
sud -schema. 

-a list snail be maintained which shall associate all 
the logical database records aetinej in the 
suo-schema with tm specified ent i t ies ue f ineo by 
tne Schema Processor (there need not be a one-to-one 
correspon jence) . A li„t of sub-schema specified 
locks shall also b<2 maintained. 
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e maintained which associates field 
in the suo-scnema with specifiea 
s previously aefineo in the schema. 
I also contain a description of tha 
cteristics of each field defined by 
These characteristics may differ 
cteristics of the corresponding 
ned in the schema. The OBM will rn^ke 
oafa conv/er si ens at run-time. A list 
applied djdinst e^ch field shj I I also 



-a report showing any in: onsi st>snc i es (such <as 
missing entify_key definitions within the 
suQ-^chenia) will oe generated. Also* if an entity 
is referenced Dy tne suo-schema which is dependent 
to an entity in another data_rel a t ion, then whenever 
a depenoent entity is added to or deleted from the 
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dafaoase, a "hidden" cro ss_re i a 1 1 on file musr be 
updaTed. AH possibilities of such "hiaaen" sidi 
effects shal I be reported out. 



3.5 Data Manipulation 

The 3HL shall be implemented through the uic cf CALL 
statements. The following functions will be supported: 

-OPEN 
raaka a sub-schema available for update or 
retrieval-only (all necessar/ files, such as 
jata_re I a tion s, key„re I a t i ons and cross_re I a f ion s, 
shall oe attached anu opened by the OBM run- time 
routines -- prowiJed the user has access to all th-. 

filcS). 

-STQ^E 
a new record with all its fielas (which may oe njl < 
v/ulued) will be placed on the Uataoase -- the user 
must provide a non-null entiry_key and its value 
as well as the fie I a names and values to ce 
associated with the specified record. 

-FINO 
retrieve a specified record and its associated 
fielo values as defined oy Tha sub-schema. 

-MODIFY 
modify a specifiej recoru or field value(s) to 
equal a given set of vslues. 

-QcLEFc 
remove from the dataoase a speci f i ed record or 
field value (s) satisfying a given set of 
conditions? also remote all relevant Jinhages. 

-CLEANPOINT 
the segments within The suo-schema whicn have been 
altered since the last CLEANPOINT command was 
issued shall be maae eligiple to be dumped to tape 
with tne Multics Backup facility. 

-CLOSE 
ThQ sub-schema shall be releaseu from the user 
application program (all associated files snail be 
closeo and uefached). 



Additional functionality, sucn as alyeoraic operations, 
may be aoaed at a Jarer time. However, it may oe aovisaole for 
sucn capaoiiifias to oe provide J by Separate 
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end-user- f aci liti es» rather fnan through PL/1. A primary 
feature of the U<1L on^ll be tnat ail references to attributes 
will be on the loyical level. The user need Know little about 
me physical arjaniiafion of the database. All references to 
jatd will oe th~ough the fielj names as defines by the user's 
suo-schems. The concept of "current logical record" shall oe 
implements d.. It shall refer to tn e last loyical record of -.-ach 
Type (as defineo in the suo-schema) to have been operated on oy 
■a SfUrtt or FIND function. These records, however, shall nor be 
explicitly referred to as "current" records. They shall be 
rct~ievej oy usa of rne FINu function with an argument to 
i'UiCatt "first," 'next* or 'all' records satisfying some 
csndi f ion. 



3.6 operational Considerations 

-Recovery/ Inteyri fy 

A means of insuring database integrity shall 
oe sn essential part of the system. The OBM shall 
take cart; to upoate all linkages whenever a datum 
is modified by a user application program. If 
uesired, "oefore" and/or "after" images of all 
altered segments could oe Journalized oy being 
written to auxiliary files and dumped to tape 
periodically using the Multics oAiJKUP facility. 
Tne overhead for such protection may be high. it 
is not clear at tnis time how much should oe 
provided in this area. 

Anotner possibility is that all updates be 
written t- a re±<irvz: area before actually oeing 
"posted" to tne dataoase. Again, tne overnead 
price for such a procedure would oe considerable. 

tony term recovery procedures must also ce 
provided for those instances when part of the 
database is inadvertantly destroyed. The backup 
tapes ci.n be used to oring such a Destroyed 
oataDsse back up to its current state of integrity. 
This requires, however, that the backup tapes 
contain "clean" data. This becomes especially 
relevant when dealing with multi-segment files, 
since ObM linkajes in one segment may reflect a 
differenr sTate tnan those in another segment. To 
this ena, the UdM must estao I i jti some intelligent 
communication interface wi tn the OAUKUP facility if 
it is to be usej to advantage. Us^r-ini tiat ed 
CLEuHPOINTs will contribute toward such a goal. ai 
will UdM initiated CLLANPOINTs. The OciM will dump 
updated segments only after if nas assured itself 
thaT all segments Xo 02 dumped are in a ClEANPGINT 
state . 
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■Privacy/Securi t/ 

Tne UBM shall rely primarily on Access Control 
Lists to insure privacy on fhi schema, sub-scnenj 
ana relation levels. Triii snail fall unoer the 
responsioi I i ty of the Oatdoase A amini st ra f or . 
Provisions will oe indue To proviOe the future 
capaDiiity to LOCK and UNLOCK irems at tne 
attribute level. 

•Concurrent Upaate 

Concurrent update of a sub-schema shall not oe 
protected. This feature m a y be provider in tne 
future. 



4-. OiiM Support Software 



Tn e support software to be provijeJ shall include 
utilities to load, recover jiij analyse a jataoase a^ well as 
en d-user- f aci I i t y. 



or 



k.l LOoO an J Unload Utility 



The Load Utility, written in PL/1, shall ce assigned Tc 
run do an absentee process, wnich hi I I accept parameters 
defining tne ra* aafa to be loaded. Th« Load Utility will 
generate all necessary urnque_ijs ana will loaa all rcJev/anf 
linkage files (wnich will previously have been created oy the 
Schema Processor). The aatabase referenced by the Load utility 
snail De tnat dataoase defined by th schema (rather than a 
suo-schems) . The LDad Utility shall normally oe tne 
rcsponsioi J i t y of tne database administrator. 



I ht Jn I oaJ Utility shall 
o~ selected portions of 



signed to dump to taoe all 
a database, including all 
ystem j a t a such as pointers 



be de 
s and directories. 



"e levant 



4.2 Recovery Utility 



Tne Recovery Utility shall interface wifn the rtultic 
BACKUP facility to provide for "clean" uaraoase recovery, 
recovery snail oe as automatic as possible. 



Th, 



4. 3 Ana lysis Utility 



ft Utility to analyse tne Si2e of data_re I at i ons , 
Hey_re I at ions and cross_re la 1 1 ons snail be proviaed. Tne 
Analysis Utility shall also serve as a verification ai3 in 
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jctirminng The exiifertctt or lack tnereof, of linkages between 
tne entities of various oa ta_re I a ti, oni. 



H.4- tnj- JSer-Faci I i t y 

Some type of en J-u jer-f aci I i ty shall be provided at some 
timet Ihis facility snail include out not oe limited ro the 
following Capaoi I i f it ss 

•Bfijledii retrievals 

- c omputa t i on s 

- sor tii 3 

•creation of aggregate datasets 

--eport generation 



<+.b Instrumentation 

Some provision should oe made for measuring D8M performsncet 
5v,mi oovious areas to examine would be the time required to 
pcrtorm overnead I aoor, such as pointer updating, the time 
rtd-jirdJ to retrieve entities par t i Ci pa f ing in different 
structures and the time required to r«sponj to a request in an 
interactive environment. 



